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Characterization of Proposed Standards 


Abstract 


RFC 2026 describes the review performed by the Internet Engineering 
Steering Group (IESG) on IETF Proposed Standard RFCs and 
characterizes the maturity level of those documents. This document 
updates RFC 2026 by providing a current and more accurate 
characterization of Proposed Standards. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 
(IETF). It has been approved for publication by the Internet 
Engineering Steering Group (IESG). Further information on BCPs is 
available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7127. 


Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


In the two decades after publication of RFC 2026 [RFC2026], the IETF 
has evolved its review processes of Proposed Standard RFCs, and thus 
Section 4.1.1 of RFC 2026 no longer accurately describes IETF 
Proposed Standards. 


This document only updates the characterization of Proposed Standards 
from Section 4.1.1 of RFC 2026 and does not speak to or alter the 
procedures for the maintenance of Standards Track documents from RFC 
2026 and RFC 6410 [RFC6410]. For complete understanding of the 
requirements for standardization, those documents should be read in 
conjunction with this document. 


2. IETF Review of Proposed Standards 


The entry-level maturity for the standards track is "Proposed 


Standard". A specific action by the IESG is required to move a 
specification onto the Standards Track at the "Proposed Standard" 
level. 


Initially it was intended that most IETF technical specifications 
would progress through a series of maturity stages starting with 
Proposed Standard, then progressing to Draft Standard, then finally 
to Internet Standard (see Section 6 of RFC 2026). For a number of 
reasons this progression is not common. Many Proposed Standards are 
actually deployed on the Internet and used extensively, as stable 
protocols. This proves the point that the community often deems it 
unnecessary to upgrade a specification to Internet Standard. Actual 
practice has been that full progression through the sequence of 
standards levels is typically quite rare, and most popular IETF 
protocols remain at Proposed Standard. Over time, the IETF has 
developed a more extensive review process. 
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IETF Proposed Standards documents have been subject to open 
development and review by the Internet technical community, generally 
including a number of formal cross-discipline reviews and, 
specifically, a security review. This is further strengthened in 
many cases by implementations and even the presence of interoperable 
code. Hence, IETF Proposed Standards are of such quality that they 
are ready for the usual market-based product development and 
deployment efforts into the Internet. 


3. Characterization of Specifications 


The text in the following section replaces Section 4.1.1 of RFC 2026. 
Section 3.2 is a verbatim copy of the characterization of Internet 
Standards from Section 4.1.3 of RFC 2026 and is provided for 
convenient reference. The text only provides the characterization; 
process issues for Draft and Internet Standards are described in RFC 
2026 and its updates, specifically RFC 6410. 


3.1. Characterization of IETF Proposed Standard Specifications 


The entry-level maturity for the standards track is "Proposed 


Standard". A specific action by the IESG is required to move a 
specification onto the standards track at the "Proposed Standard" 
level. 


A Proposed Standard specification is stable, has resolved known 
design choices, has received significant community review, and 
appears to enjoy enough community interest to be considered valuable. 


Usually, neither implementation nor operational experience is 
required for the designation of a specification as a Proposed 
Standard. However, such experience is highly desirable and will 
usually represent a strong argument in favor of a Proposed Standard 
designation. 


The IESG may require implementation and/or operational experience 
prior to granting Proposed Standard status to a specification that 
materially affects the core Internet protocols or that specifies 
behavior that may have significant operational impact on the 
Internet. 


A Proposed Standard will have no known technical omissions with 
respect to the requirements placed upon it. Proposed Standards are 
of such quality that implementations can be deployed in the Internet. 
However, as with all technical specifications, Proposed Standards may 
be revised if problems are found or better solutions are identified, 
when experiences with deploying implementations of such technologies 
at scale is gathered. 
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3.2. Characteristics of Internet Standards 


A specification for which significant implementation and successful 
operational experience has been obtained may be elevated to the 
Internet Standard level. An Internet Standard (which may simply be 
referred to as a Standard) is characterized by a high degree of 
technical maturity and by a generally held belief that the specified 
protocol or service provides significant benefit to the Internet 
community. 


4. Further Considerations 
Occasionally, the IETF may choose to publish as Proposed Standard a 
document that contains areas of known limitations or challenges. In 
such cases, any known issues with the document will be clearly and 
prominently communicated in the document, for example, in the 
abstract, the introduction, or a separate section or statement. 

5. Security Considerations 
This document does not directly affect the security of the Internet. 


6. Normative References 


[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 
3", BCP 9, RFC 2026, October 1996. 


[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 
Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 
October 2011. 
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